Dear Lucy,

I have read through the draft, it reads very well, below are my comments:

1.1 Motivation

Ice: Creating a ‘multicast’ fabric can be done with PIM/mLDP/RSVP-TE as well, this is not a specific benefit of adding tree building inside of the IGP. Note that the MVPN procedures (RFC6513) described mechanisms similar to what is proposed in this draft, i.e. create a Mi-PMSI (default fabric) and S-PMSI (specific trees). And RFC6514 describes how to use auto-provision those trees. It is not clear to me from the draft (or use-case) that there is a reason to avoid BGP.

Ice: Longer convergence times of PIM compared to unicast are due to two factors, the delay of signalling from RIB to PIM AND the amount of state (trees) that need to be updated in the PIM database. The first delay is relatively small, say order of 100ms, the cost of updating a high number of PIM/mLDP trees is higher and increases with the amount of state.

3.2.2. Parallel Local Link Selection

Quote from draft:
   “….Note that if multiple distribution trees are configured in a domain
   or on a router, better load balance among parallel links through the
   tie-breaking algorithm can be achieved. Otherwise, if there is only
   one tree is configured, then only one link in parallel links can be
   used for the corresponding distribution tree. However, calculating
   and maintaining many trees is resource consuming. Operators need to
   balance between two …."

Ice: It is very likely network operators want to take benefit of ECMP through the network, so having a single tree in the network is not an attractive option. Also, a ‘default’ single tree in the network will cause flooding and waisting of bandwidth (the nature of Tree aggregation). Putting the burden on the operators to choose their poison (Flooding or State) it not solving any problem for operators  compared to how multicast is deployed today. This is one of the key issues we need to address IMO.

3.4. Pruning a Distribution Tree for a Group

Ice: I can see it could be useful to use the link state database to build a tree, but if we’re going down the path of creating multiple trees for different receiver populations, it means you need to maintain state for each of those trees. If we now compare this with mLDP/PIM, you end up with the same amount of state, its just that it is signalled via the IGP. The way the tree is calculated in the IGP is different from how PIM/mLDP does it, but its not clear if using the IGP database is any better.

4.4. Reverse Path Forwarding Check (RPFC)

Ice: This section raises an important issue. The advantage of using the IGP database to build a tree is that it follows the (forward looking) unicast path towards its destination(s). There is no dependency on the RPF check as we know it from PIM and mLDP, which is a simplification. Not having the RPF check makes you more receptive to loops, as you indicated in this section. By adding RPFC back into the mix to prevent loops, we’re now combining the ‘forward looking’ path selection done by the upstream router and the ‘backwards looking’ (RPFC) accept mechanise on the downstream router. If there are async paths in the network there is no guarantee they select the same link, causing the downstream router to incorrectly drop the packets.


Summarising:

Using the IGP Link State Database to build an IGP Tree per Root could be useful in some scenario’s, but the lacking of RFC check make this IGP Tree much more receptive to loops. I think this is a big concern and adding back the RPF check back into the mix just complicates the solution.

Its is not clear that the procedures and mechanisms to build pruned IGP Trees are any simpler then how PIM/mLDP/RSVP-TE trees are build. When looking at the amount of state maintained in the network, its probably the same. Saying that doing IGP Tree building is better because there is no need to run an other protocol like PIM/mLDP is misleading. Obviously the procedures added into the IGP come with a cost, in complexity, state and signalling requirements. This is not something that comes for free and now everybody who understand unicast IGP knows how the multicast procedures work.

If the problem we are trying to solve is driven by ‘plug and play’ and/or auto provisioning, there are existing BGP mechanisms that we can use in combination with PIM/mLDP/RSVP-TE. 

Thx,

Ice.


> -----Original Message-----
> From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Lucy yong
> Sent: Tuesday, October 28, 2014 8:51 AM
> To: rtgwg-chairs@tools.ietf.org; rtgwg@ietf.org
> Cc: draft-yong-rtgwg-igp-multicast-arch@tools.ietf.org
> Subject: FW: New Version Notification for draft-yong-rtgwg-igp-multicast-arch-00.txt
> 
> Hello,
> 
> We upload this new draft and like to get your comments.
> 
> The subject was proposed to IS-IS WG first. AD suggested splitting the original proposal into two: IGP multicast architecture and IS-IS protocol extension, and work out the architecture in RTG WG. 
> 
> We will present this in Honolulu.
> 
> Thanks,
> Lucy
> 
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
> Sent: Monday, October 27, 2014 4:54 PM
> To: Andrew Qu; Jon Hudson; Lucy yong; Haoweiguo; Lucy yong; Donald Eastlake; Andrew Qu; Donald E. Eastlake 3rd; Jon Hudson; Haoweiguo
> Subject: New Version Notification for draft-yong-rtgwg-igp-multicast-arch-00.txt
> 
> 
> A new version of I-D, draft-yong-rtgwg-igp-multicast-arch-00.txt
> has been successfully submitted by Lucy Yong and posted to the IETF repository.
> 
> Name:		draft-yong-rtgwg-igp-multicast-arch
> Revision:	00
> Title:		IGP Multicast Architecture
> Document date:	2014-10-27
> Group:		Individual Submission
> Pages:		13
> URL:            http://www.ietf.org/internet-drafts/draft-yong-rtgwg-igp-multicast-arch-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-yong-rtgwg-igp-multicast-arch/
> Htmlized:       http://tools.ietf.org/html/draft-yong-rtgwg-igp-multicast-arch-00
> 
> 
> Abstract:
> This document specifies Interior Gateway Protocol (IGP) network architecture to support multicast transport. It describes the architecture components and the algorithms to automatically build a distribution tree for transporting multicast traffic and provides a method of pruning that tree for improved efficiency.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg